home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 368 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB

  1. From: kanze@gabi.gabi-soft.fr (J. Kanze)
  2. Message-ID: <KANZE.96Feb9160930@gabi.gabi-soft.fr>
  3. X-Original-Date: 09 Feb 1996 15:09:30 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 09 Feb 96 15:41:46 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: class.union questions
  9. Organization: GABI Software, Sarl.
  10. References: <v01530500ad38ee830c96@[194.163.74.11]>
  11.     <KANZE.96Feb5132431@slsvewt.lts.sel.alcatel.de>
  12.     <4f7l8h$t0e@mulga.cs.mu.OZ.AU>
  13. In-Reply-To: fjh@munta.cs.mu.OZ.AU's message of 06 Feb 1996 10:27:03 PST
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBFAgUBMRtrV+EDnX0m9pzZAQGlagF/aADjuW1sBao2z96gg67ENHp5Ko553eRV
  16.     W59j4JjGGGlT8LtuMr3PuHMhySaRrb+v
  17.     =YXRJ
  18.  
  19. In article <4f7l8h$t0e@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
  20. Henderson) writes:
  21.  
  22. > kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
  23. > >dirk@becker.adviser.com (Dirk Becker) writes:
  24. > >
  25. > >|> In Section 9.6.1 Unions [class.union] there is a large collection of
  26. > >|> restrictions on the union itself and on candidate member classes.
  27. > >|> I would like to ask for reasons of several of them:
  28. > >
  29. > >One of the principle goals was that a union be compatible with a C
  30. > >union, at least in use.  One of the rules is that the addresses of all
  31. > >of the elements in the union compare equal to the address of the union
  32. > >itself, when cast to the appropriate type.
  33. > >
  34. > >|> a)  "A union shall not have base classes. A union shall not be used as
  35. > >|>      a base class."
  36. > >
  37. > >Without this rule, you either break the address rule, or you impose
  38. > >some special class layout on unions.
  39. > Nevertheless, contrary to what you seem to be implying,
  40. > that rule is not necessary for C compatibility.
  41. > C++ structs can be very different to C structs, but C compatibility
  42. > is preserved for a certain category of C++ structs, namely POD-structs.
  43. > In the case of unions, the same thing could have been done -
  44. > rule (a) could have been dropped, yet C compatibility could still
  45. > have been be supported for POD-unions.
  46.  
  47. True.  But there is one intuitive fact that remains true for all
  48. structs: different (data) members have distinct addresses, and in fact
  49. occupy non-overlapping memory.  The same intuitive fact for unions is
  50. that all (non-static) data members have the same address.  (IMHO, of
  51. course.)
  52.  
  53. There is one restriction that does seem to me totally ungrounded: not
  54. being able to inherit from a union.  I don't think that this feature
  55. would be enormously useful, but I cannot think of a good reason why it
  56. should be banned.  One of the classic solutions for handling C/C++
  57. compatibility is to put all of the data in a PODS, and inherit from it,
  58. using the derived class in C++, but allowing a pointer to it to
  59. automatically become a pointer to the PODS when passed to a C function
  60. declared to take such an address.  The same argument could certainly be
  61. used for inheriting from unions.  If I look in /usr/include/sys, I find
  62. lots of unions which could be potentially used this way.
  63. -- 
  64. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  65. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  66. Conseils, itudes et rialisations en logiciel orienti objet --
  67.               -- A la recherche d'une activiti dans une region francophone
  68. ---
  69. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  70.   Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  71.   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  72.